Stop the CLI launcher from re-downloading an already-installed binary on every launch - #1316
Open
picklem0b wants to merge 1 commit into
Open
Conversation
…y launch When ~/.config/manicode/<pkg>-metadata.json is missing or unreadable (a lost cache, a cleaned config dir, an interrupted install), getCurrentVersion() returned null and the launcher read that as "not installed" — re-downloading the full platform binary on every launch even though the correct binary was already installed, and hard-failing at startup when the release host was unreachable. The metadata is only a cache of what was installed, so a lost cache must not cost a full re-download. The launcher now treats a present binary as installed when no metadata is available to contradict it: ensureBinaryReady() returns early, and the background update check compares the wrapper version (which its release binary shares) against the registry instead of assuming "unknown" means "outdated". Genuine updates still flow — the background check downloads as soon as the registry is ahead of the wrapper — and fresh installs without a binary still download normally. Also adds a CODEBUFF_NPM_REGISTRY_URL override (mirroring the existing NEXT_PUBLIC_CODEBUFF_APP_URL release-host override) so the version check can be answered by a test-controlled server, and a test suite covering the installed-binary/metadata path and the download-fallback behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
// markdown
Summary
Fixes a launcher bug where a healthy install re-downloads the full platform binary on every launch and hard-fails at startup when the release host is unreachable whenever
/.config/manicode/freebuff-metadata.json is missing or unreadable, even though the correct binary is already installed at `/.config/manicode/freebuffOriginal failure
The launcher decides "is a binary installed?" from getCurrentVersion()`, which reads the 'freebuff-metadata.json cache. When that file is missing or corrupt (cleaned config dir, interrupted install, lost cache):
ensureBinaryReady() treated 'null' as "not installed" and re-downloaded the full platform binary on every launch.
If the release host was unreachable at that moment, the launcher printed "Failed to determine latest version" and exited turning a lost cache file into a hard startup failure.
The background update check had the same bug:
currentVersion null meant "download now", so even an up-to-date install re-downloaded its binary once per session.
Root cause
The metadata file is only a cache of what was installed, but the launcher treated an unreadable cache as proof that nothing was installed. The binary itself the thing that actually matters was never checked on this path.
Solution
ensureBinaryReady()` returns early when the metadata is missing/unreadable and the binary is present. Staleness is the background update check's job; startup only needs the binary to exist.
checkForUpdates()` compares a "comparison version" that prefers the verified installed version, then falls back to the wrapper version (a wrapper and the binary it installs share a version) a lost cache no SO longer reads as "outdated", while genuine updates still download as soon as the registry is ahead.
Fresh installs (no binary) are unchanged and still download on first launch.
Added a 'CODEBUFF_NPM_REGISTRY_URL override (mirroring the existing NEXT_PUBLIC_CODEBUFF_APP_URL release-host override) so the version check can be answered by a controlled server in tests.
Tests
New cli/src/tests/release/launcher-installed-binary. test.ts (10 tests):
Verified against the pre-fix launcher: 6 of the 10 tests fail (including the re-download and the Update available: null all 10 pass with output); the fix. Existing launcher/release suites still pass (
cli/src/_tests_/release/^, launcher-avx2-fallback,wrapper-safety,proxy-http-get).